The present disclosure relates generally to database management systems and, in particular, to a method, system, and computer program product for implementing back up history cleanup operations for a database management system that supports version control of back up copies.
Database management systems perform a variety of tasks including tracking back up copies of data sets (e.g., table space or index space). Typically, the copies are tracked in some type of history table. For example, IBM®'s DB2 for z/OS database server uses a database table called SYSIBM.SYSCOPY to record the performed copies. The term “copy” refers to the backup of the table space or index space. Each row in the history table represents a copy. A typical database management application can have thousands of table spaces and, as a result, the history table contains many rows. Based upon the back up and history cleanup strategy in place, a certain number of copies per table space or index space are retained.
For operating systems that support versioning control (e.g., IBM z/OS data set type called “Generation Data Group” or “GDG”), it is possible to define the amount of versions per data set. If the number of versions is reached, the creation of a new version leads to the deletion of the oldest version, thereby ensuring that the number of versions will not be exceeded.
This mechanism works well for performing database management system copies in that only the defined number of copies will physically be stored on a disk. However, this does not affect the contents of the history table. In order to synchronize the history table to accurately reflect the copies physically stored on disk, some database management systems include a utility especially designed to perform housekeeping on the history file. For example, IBM® DB2 uses a utility called MODIFY RECOVERY to enable an administrator to delete rows that are no longer needed in the history table. MODIFY RECOVERY also supports several options to define the scope of the deletion. One option is GDGLIMIT, which queries the operating system for the definition of the GDG and cleans up the history table (e.g., SYSIBM.SYSCOPY) accordingly. Other options of MODIFY RECOVERY include AGE and DATE. AGE specifies the number of days to retain records in the history file. The option DATE may be used to delete all records in the history file that are older than a specified date.
Cleanup operations that utilize a version control limit (e.g., GDGLIMIT) are able to retain a certain number of records in the history file. In general, the processes involved consider history records only if they were made to a particular destination type (e.g., local primary) and are of a certain back up type (e.g., full image copy). Thus, in the above example, the version control limit applies only if the most recent full image copy with a destination type of local primary is a copy to a specified version control base (e.g., back up time intervals). In this instance, the version control limit is retrieved and the history table is scanned until the version control limit is reached. The date of the oldest version is used as the deletion date and all records in the history file that are older than this deletion date are deleted. Records are counted only if they belong to the version control base of the most recent record. Copies to different version control bases are skipped, as well as incremental copies. As a result, problems with recovery operations arise if more than one version control base is used for copies of the same table space. A version control base may be defined as a time interval used in specifying when a back up is to be performed (e.g., daily, weekly, monthly).
Some known causes of ineffective cleanup operations include situations in which copies of a table space have different version control bases (e.g., monthly with a version control limit of 12 and daily with a version control limit of 30), a failure to differentiate between copies at different locations (e.g., local and recovery site copy), and copies triggered for different reasons (e.g., manually entered by an administrator or automatically by a tool).
In these cases, the results of the cleanup operations may be unpredictable and depend upon which version control base was last to be used in the cleanup process. As a result, this may lead to deletion of records for copies that still exist in storage.
What is needed, therefore, is a way to implement backup history cleanup operations that factor in elements, such as version control bases, location of copies, and type of back up involved.